home *** CD-ROM | disk | FTP | other *** search
/ Software Vault: The Gold Collection / Software Vault - The Gold Collection (American Databankers) (1993).ISO / cdr11 / ppp_rfc.zip / RFC1333.TXT next >
Text File  |  1993-06-14  |  23KB  |  677 lines
  1. Network Working Group                                         W. Simpson
  2. Request for Comments: 1333                                    Daydreamer
  3.                                 May 1992
  4.  
  5.  
  6.  
  7.               PPP Link Quality Monitoring
  8.  
  9.  
  10.  
  11. Status of this Memo
  12.  
  13.    This RFC specifies an IAB standards track protocol for the Internet
  14.    community, and requests discussion and suggestions for improvements.
  15.    Please refer to the current edition of the "IAB Official Protocol
  16.    Standards" for the standardization state and status of this protocol.
  17.    Distribution of this memo is unlimited.
  18.  
  19. Abstract
  20.  
  21.    The Point-to-Point Protocol (PPP) [1] provides a standard method of
  22.    encapsulating Network Layer protocol information over point-to-point
  23.    links.  PPP also defines an extensible Link Control Protocol, which
  24.    allows negotiation of a Quality Protocol for continuous monitoring of
  25.    the viability of the link.
  26.  
  27.    This document defines a protocol for generating Link-Quality-Reports.
  28.  
  29.    This RFC is a product of the Point-to-Point Protocol Working Group of
  30.    the Internet Engineering Task Force (IETF).  Comments on this memo
  31.    should be submitted to the ietf-ppp@ucdavis.edu mailing list.
  32.  
  33.  
  34.  
  35.  
  36.  
  37.  
  38.  
  39.  
  40.  
  41.  
  42.  
  43.  
  44.  
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52. Simpson                                                         [Page i]
  53.  
  54. RFC 1333              PPP Link Quality Monitoring               May 1992
  55.  
  56.  
  57. Table of Contents
  58.  
  59.  
  60.      1.     Introduction ..........................................    1
  61.  
  62.      2.     Link Quality Monitoring ...............................    2
  63.     2.1       Design Motivation ...............................    2
  64.     2.2       Counters ........................................    2
  65.     2.3       Counting Packets and Octets .....................    4
  66.     2.4       Processes .......................................    4
  67.     2.5       Configuration Option Format .....................    6
  68.     2.6       Packet Format ...................................    8
  69.     2.7       Transmission of Reports .........................   12
  70.     2.8       Calculations ....................................   12
  71.     2.9       Failure Detection ...............................   13
  72.     2.10      Policy Suggestions ..............................   14
  73.  
  74.      SECURITY CONSIDERATIONS ......................................   14
  75.  
  76.      REFERENCES ...................................................   14
  77.  
  78.      ACKNOWLEDGEMENTS .............................................   14
  79.  
  80.      CHAIR'S ADDRESS ..............................................   15
  81.  
  82.      AUTHOR'S ADDRESS .............................................   15
  83.  
  84.  
  85.  
  86.  
  87.  
  88.  
  89.  
  90.  
  91.  
  92.  
  93.  
  94.  
  95.  
  96.  
  97.  
  98.  
  99.  
  100.  
  101.  
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108. Simpson                                                        [Page ii]
  109.  
  110. RFC 1333              PPP Link Quality Monitoring               May 1992
  111.  
  112.  
  113. 1.  Introduction
  114.  
  115.    PPP has three main components:
  116.  
  117.       1. A method for encapsulating datagrams over serial links.
  118.  
  119.       2. A Link Control Protocol (LCP) for establishing, configuring,
  120.      and testing the data-link connection.
  121.  
  122.       3. A family of Network Control Protocols (NCPs) for establishing
  123.      and configuring different network-layer protocols.
  124.  
  125.    In order to establish communications over a point-to-point link, each
  126.    end of the PPP link must first send LCP packets to configure the data
  127.    link during the Establishment phase.  During the Authentication and
  128.    Network-Layer Protocol phases, the link may be tested to determine if
  129.    quality is sufficient for operation.  This testing is completely
  130.    optional.
  131.  
  132.    If an implementation desires that the peer use some specific link
  133.    quality monitoring protocol, then it MUST negotiate the use of that
  134.    protocol using the Quality-Protocol Configuration Option during Link
  135.    Establishment phase.
  136.  
  137.    The negotiation mechanism is independent in each direction.  However,
  138.    if the peer agrees to send Quality-Protocol packets, it MUST
  139.    correctly process such packet.
  140. s on reception, even if it does not
  141.    request such packets or implement a monitoring policy.
  142.  
  143.  
  144.  
  145.  
  146.  
  147.  
  148.  
  149.  
  150.  
  151.  
  152.  
  153.  
  154.  
  155.  
  156.  
  157.  
  158.  
  159.  
  160.  
  161.  
  162.  
  163.  
  164.  
  165. Simpson                                                         [Page 1]
  166.  
  167. RFC 1333              PPP Link Quality Monitoring               May 1992
  168.  
  169.  
  170. 2.  Link Quality Monitoring
  171.  
  172.    Data communications links are rarely perfect.  Packets can be dropped
  173.    or corrupted for various reasons (line noise, equipment failure,
  174.    buffer overruns, etc.).  Sometimes, it is desirable to determine
  175.    when, and how often, the link is dropping data.  Routers, for
  176.    example, may want to temporarily allow another route to take
  177.    precedence.  An implementation may also have the option of
  178.    disconnecting and switching to an alternate link.  The process of
  179.    determining data loss is called "Link Quality Monitoring".
  180.  
  181. 2.1.  Design Motivation
  182.  
  183.    There are many different ways to measure link quality, and even more
  184.    ways to react to it.  Rather than specifying a single scheme, Link
  185.    Quality Monitoring is divided into a "mechanism" and a "policy".  PPP
  186.    fully specifies the "mechanism" for Link Quality Monitoring by
  187.    defining the Link-Quality-Report (LQR) packet and specifying a
  188.    procedure for its use.  PPP does NOT specify a Link Quality
  189.    Monitoring "policy" -- how to judge link quality or what to do when
  190.    it is inadequate.  That is left as an implementation decision, and
  191.    can be different at each end of the link.  Implementations are
  192.    allowed, and even encouraged, to experiment with various link quality
  193.    policies.  The Link Quality Monitoring mechanism specification
  194.    insures that two implementations with different policies may
  195.    communicate and interoperate.
  196.  
  197.    To allow flexible policies to be implemented, the PPP Link Quality
  198.    Monitoring mechanism measures data loss in units of packets, octets,
  199.    and Link-Quality-Reports.  Each measurement is made separately for
  200.    each half of the link, both inbound and outbound.  All measurements
  201.    are com. municated to both ends of the link so that each end of the
  202.    link can implement its own link quality policy for both its outbound
  203.    and inbound links.
  204.  
  205.    Finally, the Link Quality Monitoring protocol is designed to be
  206.    implementable on many different kinds of systems.  Although it may be
  207.    common to implement PPP (and especially Link Quality Monitoring) as a
  208.    single software process, multi-process implementations with hardware
  209.    support are also envisioned.  The PPP Link Quality Monitoring
  210.    mechanism provides for this by careful definition of the Link-
  211.    Quality-Report packet format, and by specifying reference points for
  212.    all data transmission and reception measurements.
  213.  
  214. 2.2.  Counters
  215.  
  216.    Each Link Quality Monitoring implementation maintains counts of the
  217.    number of packets and octets transmitted and successfully received,
  218.  
  219.  
  220.  
  221. Simpson                                                         [Page 2]
  222.  
  223. RFC 1333              PPP Link Quality Monitoring               May 1992
  224.  
  225.  
  226.    and periodically transmits this information to its peer in a Link-
  227.    Quality-Report packet.
  228.  
  229.    These counters are similar to sequence numbers; they are constantly
  230.    increasing to give a "relative" indication of the number of packets
  231.    and octets communicated across the outbound link.  By comparing the
  232.    values in successive Link-Quality-Reports, an LQR receiver can
  233.    compute the "delta" number of packets and octets successfully
  234.    communicated across the link.  Comparing these absolute numbers then
  235.    gives an indication of a link's quality.  Relative numbers, rather
  236.    than absolute, are transmitted because they greatly simplify link
  237.    synchronization.
  238.  
  239.    The Link-Quality-Report uses the Interface counters defined by SNMP
  240.    MIB-II [2].  These counters are not initialized to any particular
  241.    value when the LCP enters the Establishment phase.
  242.  
  243.    In addition, the Link-Quality-Report requires the implementation of
  244.    the following three unsigned, monotonically increas.
  245. ing counters which conform to the type and size requirements for SNMP MIB Counters [3].
  246.  
  247.    OutLQRs
  248.  
  249.       OutLQRs is a 32-bit counter which increases by one for each
  250.       tranmitted Link-Quality-Report packet.  This counter MUST be set
  251.       to zero when the LCP enters the Establishment phase, and MUST NOT
  252.       be reset until the LCP leaves the Termination phase.  This counter
  253.       is incremented before it is inserted into the LQR packet.
  254.  
  255.    InLQRs
  256.  
  257.       InLQRs is a 32-bit counter which increases by one for each
  258.       received Link-Quality-Report packet.  This counter MUST be set to
  259.       zero when the LCP enters the Establishment phase, and MUST NOT be
  260.       reset until the LCP leaves the Termination phase.  This counter is
  261.       incremented before it is inserted (in an implementation dependent
  262.       fashion) into the LQR packet.
  263.  
  264.    InGoodOctets
  265.  
  266.       InGoodOctets is a 32-bit counter which increases by the number of
  267.       octets in each successfully received Data Link Layer packet.
  268.       Unlike the MIB ifInOctets, octets for frames which are counted in
  269.       ifInDiscards and ifInErrors MUST NOT be counted.  This counter MAY
  270.       be set to any initial value when the LCP enters the Establishment
  271.       phase, but MUST NOT be reset until the LCP leaves the Termination
  272.       phase.
  273.  
  274.  
  275.  
  276.  
  277. Simpson                                                         [Page 3]
  278.  
  279. RFC 1333              PPP Link Quality Monitoring               May 1992
  280.  
  281.  
  282. 2.3.  Counting Packets and Octets
  283.  
  284.    The intent of the counters is to provide an indication of the amount
  285.    of information passing over the link, rather than an actual
  286.    measurement of the total bandwidth used.  This specification is
  287.    designed to yield the same count in various circumstances, such as
  288.    when a separate device provides the framing and escaping mechanisms
  289.    invisibly to the implementation, or a synchronous-to-asynchronous
  290.    converter in the link changes between mechanisms.
  291.  
  292.    All octets which are included in the FCS calculation MUST be counted,
  293.    including the packet header, the information field, and any padding.
  294.    The FCS octets MUST also be counted, and one flag octet per frame
  295.    MUST be counted.  All other octets (such as additional flag
  296.    sequences, and escape bits or octets) MUST NOT be counted.
  297.  
  298.    When inserting the packet and octet counts in the LQR, the counts
  299.    MUST include the expected values for the LQR itself.
  300.  
  301. 2.4.  Processes
  302.  
  303.    The PPP Link Quality Monitoring mechanism is described using a
  304.    "logical process" model.  As shown below, there are five logical
  305.    processes duplicated at each end of the duplex link.
  306.  
  307.    +---------+   +-------+   +----+ Outbound
  308.    |         |-->|  Mux  |-->| Tx |=========>
  309.    | Link-   |   +-------+   +----+
  310.    | Manager |
  311.    |         |   +-------+   +----+ Inbound
  312.    |         |<--| Demux |<--| Rx |<=========
  313.    +---------+   +-------+   +----+
  314.  
  315.    Link-Manager
  316.  
  317.       The Link-Manager process transmits and receives Link-Quality-
  318.       Reports, and implements the desired link quality policy.  LQR
  319.       packets are transmitted at a constant rate, which is negotiated by
  320.       the LCP Quality-Protocol Configuration Option.
  321.  
  322.    Mux
  323.  
  324.       The Mux process multiplexes packets from the various protocols
  325.       (e.g., LCP, IP, XNS, etc.) into a single, sequential, and
  326.       prioritized stream of packets.  Link-Quality-Report packets MUST
  327.       be given the highest possible priority to insure that link quality
  328.       information is communicated in a timely manner.
  329.  
  330.  
  331.  
  332.  
  333. Simpson                                                         [Page 4]
  334.  
  335. RFC 1333              PPP Link Quality Monitoring               May 1992
  336.  
  337.  
  338.    Tx
  339.  
  340.       The Tx process maintains the MIB counters ifOutUniPackets and
  341.       ifOutOctets, and the internal counter OutLQRs, which are used to
  342.       measure the amount of data which is transmitted on the outbound
  343.       link.  When Tx processes a Link-Quality-Report packet, it inserts
  344.       the values of these counters into the corresponding PeerOut...
  345.       fields of the packet.  The Tx process MUST follow the Mux process
  346.       so that packets are counted in the order transmitted to the link.
  347.  
  348.    Rx
  349.  
  350.       The Rx process maintains the MIB counters ifInUniPackets,
  351.       ifInDiscards, ifInErrors and IfInOctets, and the internal counters
  352.       InLQRs and InGoodOctets, which are used to measure the amount of
  353.       data which is received by the inbound link.  When Rx processes a
  354.       Link-Quality-Report packet, it inserts the values of these
  355.       counters into the corresponding SaveIn... fields of the packet (in
  356.       an implementation dependent manner).
  357.  
  358.    Demux
  359.  
  360.       The Demux process demultiplexes packets for the various protocols.
  361.       The Demux process MUST follow the Rx process so that packets are
  362.       counted in the order received from the link.
  363.  
  364.  
  365.  
  366.  
  367.  
  368.  
  369.  
  370.  
  371.  
  372.  
  373.  
  374.  
  375.  
  376.  
  377.  
  378.  
  379.  
  380.  
  381.  
  382.  
  383.  
  384.  
  385.  
  386.  
  387.  
  388.  
  389. Simpson                                                         [Page 5]
  390.  
  391. RFC 1333              PPP Link Quality Monitoring               May 1992
  392.  
  393.  
  394. 2.5.  Configuration Option Format
  395.  
  396.  
  397.    Description
  398.  
  399.       Implementations MUST be prepared to receive the Quality-Protocol
  400.       Configuration Option for the Link-Quality-Report.  However,
  401.       negotiation is not required.  Negotiation is only necessary when
  402.       the implementation wishes to ensure that the peer transmits Link-
  403.       Quality-Reports as opposed to some other Quality-Protocol, or else
  404.       to prevent the peer from maintaining its own timer, or else to
  405.       establish a maximum time between transmissions of Link-Quality-
  406.       Reports.
  407.  
  408.    A summary of the Quality-Protocol Configuration Option format to
  409.    negotiate the Link-Quality-Report is shown below.  The fields are
  410.    transmitted from left to right.
  411.  
  412.     0                   1                   2                   3
  413.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  414.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  415.    |     Type      |    Length .
  416.     |        Quality-Protocol       |
  417.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  418.    |                      Reporting-Period                         |
  419.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  420.  
  421.    Type
  422.  
  423.       4
  424.  
  425.    Length
  426.  
  427.       8
  428.  
  429.    Quality-Protocol
  430.  
  431.       c025 (hex) for Link-Quality-Report
  432.  
  433.    Reporting-Period
  434.  
  435.       The Reporting-Period field is four octets and indicates the
  436.       maximum time in hundredths of seconds between transmission of
  437.       packets.  The peer MAY transmit packets at a faster rate than that
  438.       which was negotiated.
  439.  
  440.       A value of zero indicates that the peer does not need to maintain
  441.       a timer.  Instead, the peer generates a LQR immediately upon
  442.       receiving a LQR.  A value of zero MUST be Nak'd by the peer with
  443.  
  444.  
  445.  
  446. Simpson                                                         [Page 6]
  447.  
  448. RFC 1333              PPP Link Quality Monitoring               May 1992
  449.  
  450.  
  451.       an appropriate non-zero value when that peer has sent or will send
  452.       a Configure-Request packet containing the Quality-Protocol
  453.       Configuration Option for the Link-Quality-Report with a zero
  454.       Reporting-Period.
  455.  
  456.  
  457.  
  458.  
  459.  
  460.  
  461.  
  462.  
  463.  
  464.  
  465.  
  466.  
  467.  
  468.  
  469.  
  470.  
  471.  
  472.  
  473.  
  474.  
  475.  
  476.  
  477.  
  478.  
  479.  
  480.  
  481.  
  482.  
  483.  
  484.  
  485.  
  486.  
  487.  
  488.  
  489.  
  490.  
  491.  
  492.  
  493.  
  494.  
  495.  
  496.  
  497.  
  498.  
  499.  
  500.  
  501.  
  502. Simpson                                                         [Page 7]
  503.  
  504. RFC 1333              PPP Link Quality Monitoring               May 1992
  505.  
  506.  
  507. 2.6.  Packet Format
  508.  
  509.    Exactly one Link-Quality-Report packet is encapsulated in the
  510.    Information field of PPP Data Link Layer frames where the protocol
  511.    field indicates type hex c025 (Link-Quality-Report).  A summary of
  512.    the LQR packet format is shown below.  The names of the fields are
  513.    relative to the packet receiver, since it is the receiver who
  514.    requested the packet in the Configuration Option.  The fields are
  515.    transmitted from left to right.
  516.  
  517.     0                   1                   2                   3
  518.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  519.    +-+-.
  520. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  521.    |                         Magic-Number                          |
  522.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  523.    |                         LastOutLQRs                           |
  524.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  525.    |                        LastOutPackets                         |
  526.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  527.    |                        LastOutOctets                          |
  528.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  529.    |                         PeerInLQRs                            |
  530.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  531.    |                        PeerInPackets                          |
  532.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  533.    |                        PeerInDiscards                         |
  534.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  535.    |                        PeerInErrors                           |
  536.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  537.    |                        PeerInOctets                           |
  538.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  539.    |                         PeerOutLQRs                           |
  540.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  541.    |                        PeerOutPackets                         |
  542.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  543.    |                        PeerOutOctets                          |
  544.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  545.  
  546.    The following fields are not actually transmitted over the inbound
  547.    link.  Rather, they are logically appended (in an implementation
  548.    dependent manner) to the packet by the implementation's Rx process.
  549.  
  550.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  551.   .
  552.  |                         SaveInLQRs                            |
  553.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  554.    |                        SaveInPackets                          |
  555.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  556.    |                        SaveInDiscards                         |
  557.  
  558.  
  559.  
  560. Simpson                                                         [Page 8]
  561.  
  562. RFC 1333              PPP Link Quality Monitoring               May 1992
  563.  
  564.  
  565.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  566.    |                        SaveInErrors                           |
  567.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  568.    |                        SaveInOctets                           |
  569.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  570.  
  571.    Magic-Number
  572.  
  573.       The Magic-Number field is four octets and aids in detecting links
  574.       which are in the looped-back condition.  Unless modified by a
  575.       Configuration Option, the Magic-Number MUST be transmitted as zero
  576.       and MUST be ignored on reception.  If Magic-Numbers have been
  577.       negotiated, incoming LQR packets SHOULD be checked to ensure that
  578.       the local end is not seeing its own Magic-Number and thus a
  579.       looped-back link.  See the Magic-Number Configuration Option for
  580.       further explanation.
  581.  
  582.    LastOutLQRs
  583.  
  584.       The LastOutLQRs field is four octets, and is copied from the most
  585.       recently received PeerOutLQRs on transmission.
  586.  
  587.    LastOutPackets
  588.  
  589.       The LastOutPackets field is four octets, and is copied from the
  590.       most recently received PeerOutPackets on transmission.
  591.  
  592.    LastOutOctets
  593.  
  594.       The LastOutOctets field is four octets, and is copied from the
  595.       most recently received PeerOutOctets on transmission.
  596.  
  597.    PeerInLQRs
  598.  
  599.       The PeerInLQRs field is four octets, and is copied from the most
  600.       recently received SaveInLQRs on transmission.
  601.  
  602.       Whenever the PeerInLQRs field is disc.
  603. overed to be zero, the LastOut... fields are indeterminate, and the PeerIn... fields
  604.       contain the initial values for the peer.
  605.  
  606.    PeerInPackets
  607.  
  608.       The PeerInPackets field is four octets, and is copied from the
  609.       most recently received SaveInPackets on transmission.
  610.  
  611.  
  612.  
  613.  
  614.  
  615.  
  616. Simpson                                                         [Page 9]
  617.  
  618. RFC 1333              PPP Link Quality Monitoring               May 1992
  619.  
  620.  
  621.    PeerInDiscards
  622.  
  623.       The PeerInDiscards field is four octets, and is copied from the
  624.       most recently received SaveInDiscards on transmission.
  625.  
  626.    PeerInErrors
  627.  
  628.       The PeerInErrors field is four octets, and is copied from the most
  629.       recently received SaveInErrors on transmission.
  630.  
  631.    PeerInOctets
  632.  
  633.       The PeerInOctets field is four octets, and is copied from the most
  634.       recently received SaveInOctets on transmission.
  635.  
  636.    PeerOutLQRs
  637.  
  638.       The PeerOutLQRs field is four octets, and is copied from OutLQRs
  639.       on transmission.  This number MUST include this LQR.
  640.  
  641.    PeerOutPackets
  642.  
  643.       The PeerOutPackets field is four octets, and is copied from the
  644.       current MIB ifOutUniPackets and ifOutNUniPackets on transmission.
  645.       This number MUST include this LQR.
  646.  
  647.    PeerOutOctets
  648.  
  649.       The PeerOutOctets field is four octets, and is copied from the
  650.       current MIB ifOutOctets on transmission.  This number MUST include
  651.       this LQR.
  652.  
  653.    SaveInLQRs
  654.  
  655.       The SaveInLQRs field is four octets, and is copied from InLQRs on
  656.       reception.  This number MUST include this LQR.
  657.  
  658.    SaveInPackets
  659.  
  660.       The SaveInPackets field is four octets, and is copied from the
  661.       current MIB ifInUniPackets and ifInNUniPackets on reception.  This
  662.       number MUST include this LQR.
  663.  
  664.    SaveInDiscards
  665.  
  666.       The SaveInDiscards field is four octets, and is copied from the
  667.       current MIB ifInDiscards on reception.  This number MUST include
  668.       this LQR.
  669.  
  670.  
  671.  
  672. Simpson                                                        [Page 10]
  673.  
  674.  
  675.  
  676.  
  677.